LabVIEW Programming for Robot Control

With the high adaptability requirements for the software that controls our robots, text code based programming, such as in C++, can cause significant time delays, especially when poorly documented. Graphical programming, a new paradigm in programming, through LabVIEW, can provide a solution with a shorter learning period, faster code implementation, and easier maintainability. We have developed a LabVIEW program demonstrating the ease of programming a 5-DOF robot arm to move wooden a ring from a peg to another, simulating a typical robot chip manufacturing operation. Our successful runs suggest a promise for a facility-wide employment of LabVIEW for all our robots. Introduction Currently, the robotic systems the company employs are programmed in C++. However, the rapid advances in wireless signal processor technology lead to frequent changes in product specifications; this requires the robot software employed in our factory to be upgraded and modified very regularly. Though it is an efficient language that fulfills the requirements of controlling the robots in our production line, for the purposes of maintaining highly transient code, C++ is presently not the most suitable language. Furthermore, the existing code base is so poorly documented that each successive modification to it requires an exponential increase in time to accomplish. We feel that this has now become a bottleneck in our manufacturing process. We propose using graphical programming to reduce the time overhead required to adapt the robot code, thus minimizing programmer effort for each software upgrade cycle. In particular, we have investigated the use of National Instruments’ LabVIEW program to control a robot arm, demonstrating that the language, after an initial learning stage, does help to reduce the time and effort required to modify an existing program. With this new paradigm in programming, programmers should be able to expediently implement the changes in software needed to produce new processors, thus eliminating this stage as the limiting point in our production line. Background Drawing from the idea of schematic flow charts used to plan programs, graphical programming takes the process a step further by seamlessly bridging the gap between planning and implementation. While laying out program components in the graphical environment, coders simultaneously design and implement the software. In graphical programming, a block diagram represents a procedure analogous to a sequence of code in a text-based language. Just as text-based programming languages are comprised functions linked by syntactical structures, graphical programming languages have functions as icons linked by ‘wires’. Data output from a function can be streamed into other functions by connecting the icon terminals with wires, which can branch to allow multiple destinations per source. Each icon can have multiple inputs and outputs; a benefit over a language like C++ that does not explicitly allow the returning of more than one data variables. One written, each program is saved as a virtual instrument (VI) and can function independently. In the case of LabVIEW[1], other than the diagrammatic view, there is also a front panel view that lays out a select few of components in a graphical user interface (GUI). Designing the GUI is much in the flavour of form designers in certain integrated development environments (like Visual Basic and JBuilder). When the program is executed, the user would interact at the front panel to manipulate components such as text boxes and sliders, and view data from ready-made components such as graphs and simulated LEDs. Moreover, each VI that is written, can be made into a component as a subVI, and used as an icon, much like employing a custom written function in text-based programming languages. Each input point in the program is marked as an input terminal of its corresponding icon and each output point to an output terminal. Due to the visual nature of the language, it is easier to follow the modular structure of code implemented in a graphical language. Basic procedural language features, such as for and while loops are also available to provide means for iteration. Though the manner of programming in LabVIEW feels different from text-based languages like C, C++ and Java, it is still essentially a procedural language, so many structures employed in those languages have analogues in LabVIEW. Furthermore, even though LabVIEW is not explicitly an object-oriented language (OOL), its feature to allow the building of components and the extension of those components to augment their features can decently replicate the behavior of inheritance in OOLs. Results Using LabVIEW, we have programmed a robot arm of 5 degrees of freedom (1 for each servo controlling the waist, shoulder, elbow, wrist and gripper), to move a wooden ring from 1 wooden peg to another, simulating a typical wafer-handling operation. Servo control is through a signal carrying digital pulses of 5V and variable widths, from 1.00ms to 2.00ms, corresponding to the minimum and maximum servo angular displacements. This signal originates from the serial port of a Pentium III 500MHz encoded to represent bytes from 0 to 254, for minimum and maximum displacements respectively. The final program consists of 2 main parts – record.vi and playback.vi. record.vi provides an interface for the user to manually control the robot to articulate to certain desired positions. The user would move sliders corresponding to each servo from an ADC unit value of 0 to 254. The user can then save the checkpoint position information to a file. playback.vi reads the recorded file and repeats the locomotion, making smooth and gentle transitions from each checkpoint. This allows the trajectory to be repeated multiple times as needed by our robots when manufacturing the chips. Starting from writing a rudimentary program that simply controls individual servos, one a time, the program was easily extended to handle all 5 servos on one front panel, culminating in robotwrt.vi. It was then augmented to allow recording of the positions of the servos to file. The final form is record.vi. playback.vi was created from a similar foundation as record.vi, but with the capability to read from a file instead. It was noted that when the robot arm moved to the recorded positions, it did so in an unsatisfactorily jerky manner. This would be unacceptable in the production line for the damage to the chips that excessive motion can cause. Thus a procedure, step.vi, was written to smooth out the transitions from point to point. This was then just ‘plugged’ into playback.vi to smooth out the trajectory. Another problem encountered was the mechanical backlash in the servos, particularly for the waist and shoulder ones, manifested by the arm swinging back a little after reaching each position. This was resolved by programming the arm to move a little beyond its intended position at each checkpoint of its trajectory. Conclusions and Recommendations 1) The robot arm was successfully controlled through a LabVIEW program. 2) Learning LabVIEW is significantly faster and more intuitive than a text-based programming language, in the order of days as compared to weeks. 3) The graphical nature of the language makes it easier to visualize the schematic arrangement of programmatic components, such that it is easier to understand big programs. 4) Thus, comprehending existing LabVIEW code is much quicker and easier than text-based languages. 5) Commenting in LabVIEW is simple through an intuitive and attractive interface, promoting better code documentation for better maintenance. 6) LabVIEW is specially designed to write data acquisition and control programs, thus it is very appropriate to our needs in processor manufacturing. With this initial assessment of LabVIEW, it seems promising to implement graphical programming for all our robots in the production line. After the initial learning period, creating and modifying LabVIEW programs require far less effort than programs written in C++. To further support this move, we propose investigating the cost savings brought about by using LabVIEW, whether the time savings make up for the costs to re-train programmers and to license the software from National Instruments. We could also do a partial implementation in LabVIEW in some of our factory robots to determine any defects that may arise during run-time. Further Reading 1. Travis, Jeffery, LabVIEW for everyone, Prentice Hall, NJ, 2002. Appendix Attached are the LabVIEW code listings and documentations of relevant program files used for the robot arm control. 1. robotwrt.vi Takes numerical byte values to represent displacement positions for each servo and concatenates the data into a string to stream through the serial port of the controlling computer into the robot circuit. The circuit would then transform the signal into the relevant signal for each servo. 2. record.vi Having initialized the serial port, this allows the user to control each of the 5 servos to a location by adjusting the sliders. Robot control is delegated to robotwrt.vi. After a desired position for the arm is reached, pressing the record button would then write the positional information to a specified file. 3. playback.vi Complementing record.vi, this reads the recorded file and executes the motion of the robot arm such that it moves to each recorded position, but in a smoothed out manner due to the contribution of step.vi, by taking small step increments to arrive at each checkpoint. Robot control is delegated to robotwrt.vi. 4. step.vi Simple arithmetic operation that increments or decrements an input value to make it closer to the input target value. Refer to the further reading for explanations on the LabVIEW in-built functions and structures used.